-
Notifications
You must be signed in to change notification settings - Fork 0
Prototype gchandle #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
src/coreclr/gc/objecthandle.cpp
Outdated
// Promote the object and let the bridge indicate when the | ||
// object is actually dead. | ||
Ops* pOps = (Ops*)lp1; | ||
pOps->pfn(&pObj, pOps->sc, 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think we want to be promoting when collecting the list of potentially dead objects.
Promoting an object can end up promoting other objects recursively. Some of these other objects may be participating in the GC bridge as well, and so we would miss them when building the graph.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Promoting the objects should be a separate pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this needs more investigation. I need the GC team or more time to learn a better approach in this area.
src/coreclr/gc/objecthandle.cpp
Outdated
_ASSERTE(lp1 != NULL); | ||
_ASSERTE(lp2 != NULL); | ||
|
||
Object *pObj = VolatileLoad((PTR_Object*)pObjRef); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not need to be VolatileLoad. Nothing is touching these references while this is running.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. This was copy/paste from other callbacks.
return (void*)instHandle; | ||
} | ||
|
||
extern "C" BOOL QCALLTYPE JavaMarshal_GetContext( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be an FCall - if perf of this call matters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep.
return; | ||
} | ||
|
||
g_mcrargs = mcrargs; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seems to be a subtle race condition. If the system is overloaded and it did not get a chance to run since the last turn of the crank, we can still see g_BridgeReady
set to TRUE
, but g_mcrargs
is still going to point to the old payload that we are going to leak by overwriting the point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entire thread operation is completely dirty and a simple prototype. It all needs to be redone.
src/coreclr/vm/prestub.cpp
Outdated
@@ -2562,6 +2562,10 @@ static PCODE PreStubWorker_Preemptive( | |||
// more we can do except fail fast. The reverse P/Invoke isn't | |||
// going to work. | |||
CREATETHREAD_IF_NULL_FAILFAST(currentThread, W("Failed to setup new thread during reverse P/Invoke")); | |||
|
|||
// [TODO] Ensure thread is in Preemptive mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is a hack that will be reverted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't a hack, at least I don't think it is. There is something wrong in this code path and I'm not sure yet what it is, but it seems like a subtle bug. We are creating a thread above in CREATETHREAD_IF_NULL_FAILFAST
and it is in COOP mode. I'm unclear how anything I am doing can influence this at present. I put this in a separate commit to investigate tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are missing HasStarted
call when setting up the new thread. Creating a new thread in native CoreCLR is a complicated handshake. You may want to create the thread on the managed side - it is much easier and less bug prone to do that way, and it can be reused for NAOT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This worked. Thanks.
@jkotas I applied some of the feedback that was structural. The handshake for the bridge still needs to be redone and we can consider the FCall for |
src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/Java/JavaMarshal.cs
Outdated
Show resolved
Hide resolved
#if !NATIVEAOT | ||
private static Thread? s_bridgeThread; | ||
#endif | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#if !NATIVEAOT | |
private static Thread? s_bridgeThread; | |
#endif |
Nit: It does not need to be stored in a static.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in, just allocate it and don't worry about it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, allocate it, start it and don't worry about it.
10755d0
to
567f02c
Compare
Fixes dotnet#113923. If we are considering folding a conditional block with successors that loop back to it, don't try to compact the successors, as that will quietly remove the conditional block from the flowgraph. Instead, skip compaction, and let the cond-to-return shape check fail.
Introduce a new `CanAssignFrom` method on `ClassLayout` that will ultimately do more relaxed (and asymmetric) checking for cases that can arise from escape analysis. For now it just defers to `AreCompatible`, which is and will remain an equivalence relation (hence symmetric). Split off some callers of `AreCompatible` to call `CanAssignFrom` instead. Generally methods invoked after we run escape analysis will need to start using `CanAssignFrom` as it will introduce new layouts.
Co-authored-by: Jeremy Barton <[email protected]>
…g is set. (dotnet#113854) * Make sure KMOV is not encoded in EVEX when JitStressEvexEncoding is set. * correct comment text.
Implements `MLKemOpenSsl` and restructures tests to support testing multiple MLKem implementations.
…26.1 (dotnet#113957) Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport , Microsoft.SourceBuild.Intermediate.emsdk From Version 10.0.0-preview.4.25175.2 -> To Version 10.0.0-preview.4.25176.1 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Per [review feedback from @stephentoub](dotnet#113775 (comment)) post-merge
The build was checking to see if HAVE_OPENSSL_EVP_PKEY_SIGN_MESSAGE_INIT was defined, however because we use cmakedefine01 in the build, it is always defined. We care about the value of the define, not if it is defined or not.
* implement GetFrameName in cDAC
…et#113500) * Throw TLE if 'sequence' feature is used * Disallow loading non-Explicit types with explicit field offsets * Apply suggestions from code review Co-authored-by: Copilot <[email protected]> * Make methods local methods * Try to create an instance instead * Throw exceptions in mono and nativeaot * Fix check during non-explicit type layout. * Introduce FieldDesc.MetadataOffset remove field offsets from ClassLayoutMetadata * PR feedback and fix build for System.Private.TypeLoader * Move FieldAndOffset definition * Don't check offsets for AutoLayout * Don't error out on non-explicit offest information for sequential fields either. --------- Co-authored-by: Copilot <[email protected]>
) dotnet#113416 used a shared SString buffer when building the log message written to console when hitting an unhandled managed exception. It appears that the same buffer was used when passing data over to EventReporter, but it would then include more information than expected. This will fix so we only pass over the exception message, inline with previous beharior. Fixes issue found in dotnet/aspnetcore#61011.
This allows the consumption of newer packages in the same release band when an SDK with package pruning enabled is used.
…otnet#113951) When `CanonFormTypeMayExist` was written, it was okay for arrays to return false since arrays were always compared structurally (it was allowed to have multiple `MethodTable`s for a single array type). We stopped allowing this some time ago and we now have to maintain the same invariant as for any other `MethodTable` - the address of the `MethodTable` is the unique identity. We cannot allow the compiler to generate unconstructed `MethodTable` for something that can be template-constructed at runtime.
- Do not set RVA for empty RUNTIME_FUNCTION section in crossgen2 - Do not register empty RUNTIME_FUNCTIONs section at runtime Fixes dotnet#113117
dotnet#113916) * Adjust sources under utilcode and vm to use minipal_log API. * Review feedback. * Review feedback, convert some more info -> error logging. * Log OOM as a warning instead of info. * Fix typo.
* Stackwalk support for interpreted frames This change adds support for walking stack with interpreter frames present. The StackFrameIterator now considers the interpreter frames to be frameless frames like regular JITted / crossgened folder. This is a basis for GC, EH and debugger stack walking. The SOS `clrstack` and `clrstack -i` both display correct stack trace with interpreter frames on the stack with this change. I have added some extra handling of the case when the interpreter frames are on top of the stack so that the clrstack can dump them. * Fix VirtualUnwindInterpreterCallFrame In case we were generating the caller context, the SP and ContextFlags were missing. * Move to single InterpreterFrame and few fixes * Fix Unix build break * Prevent missing override errors on Unix build * Improve top frame lookup * Reflect PR feedback * Change the GET_CALLER_SP to assert and return NULL * Remove extra assert at the call to GET_CALLER_SP * Revert some changes removing "virtual" keyword that were not intentional * Few missing virtual keywords reverts * Revert the GetCallerSP changes * Fix MUSL build break * Add comment on top frame seeking
Also, rename some related configs to use "Jit" and not "JIT".
…otnet#114070) Match more of the Vector* intrinsics to the PackSimd interpreter intrinsics
* change FrameIdentifiers to be contract literals instead of indirect pointers * add 'TryReadGlobal' and 'TryReadGlobalPointer'
Add more detail on "the new platform-specific files" referenced in RyuJIT porting documentation. The delineation between files can be unclear to folks who aren't deeply involved with runtime internals, and outright imprenetrable to community contributors Co-authored-by: Jo Shields <[email protected]>
Some of the methods that were left on the CEEJitInfo during the code manager split are actually still useful for the interpreter, so I am moving their implementation to the common CEECodeGenInfo.
…#113888) * parallel change to diagnostic update * decoder does not need to worry about parsing GCInfo V1 * fix for unix * clarified a comment
Definition of TypeMaps APIs in BCL CoreCLR implementation of TypeMap APIs
* Update dependencies from https://github.com/dotnet/roslyn build 20250225.8 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25125.8 * Update dependencies from https://github.com/dotnet/roslyn build 20250226.5 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25126.5 * Update dependencies from https://github.com/dotnet/roslyn build 20250303.7 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25153.7 * Update dependencies from https://github.com/dotnet/roslyn build 20250304.7 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25154.7 * Update dependencies from https://github.com/dotnet/roslyn build 20250305.15 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25155.15 * Update dependencies from https://github.com/dotnet/roslyn build 20250307.4 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25157.4 * Update dependencies from https://github.com/dotnet/roslyn build 20250310.11 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25160.11 * Update dependencies from https://github.com/dotnet/roslyn build 20250311.7 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25161.7 * Update dependencies from https://github.com/dotnet/roslyn build 20250312.12 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25162.12 * Update dependencies from https://github.com/dotnet/roslyn build 20250313.9 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25163.9 * Update dependencies from https://github.com/dotnet/roslyn build 20250314.6 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25164.6 * Update dependencies from https://github.com/dotnet/roslyn build 20250314.10 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25164.10 * Update dependencies from https://github.com/dotnet/roslyn build 20250317.7 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25167.7 * Update dependencies from https://github.com/dotnet/roslyn build 20250318.15 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25168.15 * Update dependencies from https://github.com/dotnet/roslyn build 20250319.7 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25169.7 * Update dependencies from https://github.com/dotnet/roslyn build 20250320.13 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25170.13 * Update dependencies from https://github.com/dotnet/roslyn build 20250321.23 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25171.23 * Update dependencies from https://github.com/dotnet/roslyn build 20250321.27 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25171.27 * Update dependencies from https://github.com/dotnet/roslyn build 2025032.10 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25174.10 * Update dependencies from https://github.com/dotnet/roslyn build 20250325.12 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25175.12 * Update dependencies from https://github.com/dotnet/roslyn build 20250326.10 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25176.10 * Update dependencies from https://github.com/dotnet/roslyn build 20250327.9 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25177.9 * Update dependencies from https://github.com/dotnet/roslyn build 20250328.1 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25178.1 * Update dependencies from https://github.com/dotnet/roslyn build 20250329.1 Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25121.3 -> To Version 4.14.0-3.25179.1 * Fix compiler warning around unused fields - needed for Unsafe. * Allow prebuilts for roslyn's dependencies --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Larry Ewing <[email protected]> Co-authored-by: Eric StJohn <[email protected]>
…#114121) * Delete dead code in ExceptionTracker * Delete more * Delete more * Delete more * Delete more * Delete more
…e based on the delta sizes (dotnet#113995) * Fix applying hot reload changes when the delta table has a bigger len than the baseline table.
Updates the single-file bundler to use the managed Mach-O signer. Adds the SymbolTable load command to the MachObjectFile class and adds a method to extend the symbol table to include the bundled data. Adds validation when creating a MachObjectFile from a file on disk. MacOS keeps a cache of signatures of inodes, so editing an existing file in place invalidates the cache and willl fail validation. The way to work around this is to create a new file with a new inode when modifying and resigning a file on disk. Basic host signing didn't run into this issue because it modifies and signs the executable in the same step, so no re-signing happened. For singlefile bundles, we previously would modify the apphost, close the file, then in a separate step, bundle the files and re-sign it. After this PR we create a new file every time we need to re-sign the host, then replace the old host with the new one.
…tation and using `emitDataConst` (dotnet#113250) * [RISC-V] Optimize loading 64 bit constant with emitDataConst * [RISC-V] Implement an algorithm for loading immediate that yields fewer instructions * [RISC-V] Handle corner case where high32 is 0x7FFFFFFF * [RISC-V] Optimize further: move chunk window for as many as leading zeros * [RISC-V] Optimize load immidiate with SRLI instruction * [RISC-V] Clean up helper functions * [RISC-V] Bug fix: restore original imm prior to emitDataConst * [RISC-V] Correct maximum additional shift * [RISC-V] Handle all ones and all zeros as corner case * [RISC-V] Add and edit comments * [RISC-V] Return early on ValidSimm12(imm) and remove all zeros / ones check * [RISC-V] Address comments: use BitOperations, remove redundant size check, apply coding conventions * [RISC-V] Use pcrel for loading constant unless loading from cold section * [RISC-V] Make sure to not use emitDataConst + emitIns_R_C when generating prolog * [RISC-V] Don't generate emitDataConst + emitIns_R_C in epilog
* Add support for newobj The newobj instruction receives the set of arguments and it needs to create the object in question, add it as the `this` argument to the constructor and return it as well. All this work is done by a single interpreter newobj instruction. Once handling the creation of the new object, the already existing call path is reused for executing the constructor. The newobj instruction thinks it receives the `this` pointer as an argument, so we can reuse the offset allocator to generate the exact offsets for each argument. We dummy initialize `this` via an intermediary opcode, so the offset allocator handles this pattern cleanly. * Intrinsify Object ctor We currently have limited control over what is interpreted and what is jitted. When creating a new object in the interpreter we have the problem of having to call to object ctor which is jitted. A simple work around, at least for now, is to ignore this call. * Add support for fields Loading and storing into instance and static fields, as well as loading the address of fields. For instance fields, this is achieved via ldind/stind opcodes, that have the offset embedded into the instruction. For static fields, we first compute the field address and then we reuse the same ldind/stind opcodes for the field access. When loading a field from a valuetype from the interpreter stack, we use a separate opcode INTOP_MOV_SRC_OFF, which will be emitted as a normal move (with already existing opcodes), but the source offset that it operates on can point inside a VT var. * Add support for ldloca * Add support for ThreadStatic fields Special static fields can have a bunch of accessors. This commit handles a few accessor types for thread static fields. In order to obtain the address of such a field, we emit an interpreter opcode that can call a helper of a certain signature, with the slot containing the helper code pointer and argument embedded in the code stream. It seems like the helpers can either point to native code or to jit compiled code. * Zero IL locals at method entry, if initlocals flag is set * Add support for ldind/stdind instructions Reuse the instructions used for loading/storing into fields * Emit memory barriers for volatile stores/writes For simplicity we emit full memory barriers each time * Add some more tests related to field access Some of them are allocating objects so we disable them currently just to be safe on CI.
…328.2 (dotnet#114058) Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XliffTasks , Microsoft.DotNet.XUnitAssert , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions From Version 10.0.0-beta.25175.2 -> To Version 10.0.0-beta.25178.2 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Updated the `while` loop condition in `ReadCentralDirectory` to use `<=` instead of `<` for the buffer length. This change allows the loop to quickly throw if the expected number of entries is found to be incorrect due to the central directory data being malformed. Add test to verify this case by malforming the archive in a way that the while loop condition that checks for the buffer length being smaller or equal than current position + block constant section size becomes false and exits immediately.
* Sign and harden pkgs * Fix missing closing quote in MacOSPkg element * Add singlefilehost to MacOS signing list * Add new executables to MacOS signing list * Add 'Mono' to MacOS signing list * Remove inadvertently added lines --------- Co-authored-by: Alexander Köplinger <[email protected]>
There are some `on pull_request_target types` in the label checking yml files that were removed but they are actually necessary, so the labeler keeps working after for example: pushing new commits, pressing the update the branch, closing and opening the PR.
…duplication (dotnet#113044) * [SGen/Tarjan] Handle edge case with node heaviness changing due to deduplication Do early deduplication Fix Windows build Add test cases to sgen-bridge-pathologies * Move test code * Remove old code * Add extra check (no change to functionality)
Prior to check-in, update all places with "!TODO-JAVA!".
Implement scanning of the new GC Handle and calling a new VM callout to process the resulting data.
Implement the VM side of the GC Handle processing and callout to mark cross references.
3957394
to
461cf22
Compare
No description provided.